SOAFEE (Scalable Open Architecture for Embedded Edge) 소프트웨어 정의 차랑

2025-11-04, G25DR

1. SOAFEE 개요: 소프트웨어 정의 차량(SDV)을 위한 아키텍처 혁신

1.1 SOAFEE의 정의와 핵심 비전

SOAFEE (Scalable Open Architecture for Embedded Edge)는 업계 주도형 이니셔티브(industry-led initiative)로 정의된다.1 이는 자동차 산업이 기존의 하드웨어 중심 개발에서 소프트웨어 중심 개발로 이동하는 거대한 패러다임 전환을 수용하기 위해 출현한 핵심적인 기술 협력체이다. SOAFEE는 특정 기업의 독점 기술이 아닌, 자동차 제조사(OEM), 부품 공급업체(Tier 1), 반도체 기업, 소프트웨어 및 클라우드 기술 기업들이 연합하여 개발하고 발전시키는 표준화된 개방형 아키텍처이다.2

SOAFEE의 핵심 임무(Mission)는 “최신 클라우드 네이티브 개발 패러다임을 자동차 산업에 도입하는 것“이다.2 이는 지난 수십 년간 정보 기술(IT) 및 클라우드 컴퓨팅 분야에서 검증된 기술, 도구, 그리고 민첩한 개발 프랙티스를 차량용 임베디드 시스템 개발에 통합하는 것을 목표로 한다.1 파나소닉 오토모티브 시스템즈(Panasonic Automotive Systems)는 SOAFEE가 “자동차 제품에 빠르고 지속적인 제공을 가능하게 하는 원활한 클라우드 네이티브 환경을 개발“하는 비전을 공유하며, 이 목표 달성에 디바이스 가상화가 중요한 역할을 할 것이라 언급한 바 있다.1

SOAFEE의 공식 헌장(Charter)에 명시된 비전(Vision)은 “클라우드 네이티브 개발 패러다임과 그 유비쿼터스(ubiquitous) 생태계를, 차세대 자동차 및 안전 필수 시스템(safety critical systems)을 구동할 매우 다양하고 이기종적인(heterogeneous) 컴퓨팅 플랫폼에 도입하는 것“이다.4 궁극적으로 SOAFEE는 AI 기반의 소프트웨어 정의 차량(SDV, Software-Defined Vehicles)을 현실화하는 핵심 기술 프레임워크를 제공하고자 한다.1

1.2 SOAFEE의 전략적 목표 (Scope)

SOAFEE 헌장(Charter)은 상기 비전을 달성하기 위한 5대 전략적 목표(Scope)를 구체적으로 명시하고 있다.4

1. 표준 기반 아키텍처 프레임워크 제공: 클라우드에서 자동차 엣지(차량 내부)에 이르는 전체 컴퓨팅 연속체(compute continuum)에서 **혼합 중요도 워크로드(mixed critical workloads)**를 위한 클라우드 네이티브 소프트웨어 개발을 가능하게 하는 개방형 표준 기반 아키텍처 프레임워크를 제공한다.4

2. 업스트림 표준 기여: 혼합 중요도 워크로드를 위한 클라우드 네이티브 개발을 지원하기 위해 기존의 **업스트림 표준(upstream standards)**을 생성, 기여 및 채택한다.4 이는 SOAFEE가 자동차 산업만을 위한 고립된 표준을 만드는 것이 아니라, OCI(Open Container Initiative)나 Kubernetes 등 기존 클라우드 표준과 협력함을 시사한다.

3. 오픈 소스 레퍼런스 구현 제공: 개방형 소스 및 상용 솔루션 생성을 위한 생태계를 조성하고 상호 운용성을 확보하기 위해, 재구현이 자유로운 API를 포함한 **오픈 소스 레퍼런스 구현(open source reference implementations)**을 제공한다.4

4. 환경 동등성(Environmental Parity) 극대화: 클라우드와 자동차 엣지 소프트웨어 개발 간의 원활한(seamless) 흐름을 지원하고, 두 환경 간의 환경 동등성을 극대화하는 시드(seed) 개발 플랫폼을 생성한다.4

5. 상업적 생태계 활성화: 자동차 스택 전반에 걸쳐 상용 제품을 제공하는 활기찬 상업적 파트너 생태계를 활성화하여, 개발에서 실제 배포까지의 경로를 지원한다.4

SOAFEE는 기존 컨소시엄(예: AUTOSAR)이나 오픈 소스 프로젝트를 대체하거나 소비하는 것을 목표로 하지 않는다.4 대신, 이들과 협력하고 보완하며, 이들 업스트림 조직이 정의하는 인터페이스와 추상화를 상속받아 전체 스택 솔루션을 위한 플랫폼 인에이블러(enabler) 역할을 수행하는 것을 명확히 한다.4

1.3 기존 차량 개발의 한계와 SOAFEE의 필요성

SOAFEE의 등장은 필연적이다. 자동차 산업은 ADAS(첨단 운전자 보조 시스템), 자율주행(AD), 커넥티드 IVI(In-Vehicle Infotainment) 기능이 기하급수적으로 증가하며 소프트웨어 복잡성이 폭발하는 변혁기를 맞고 있다.3 SDV로의 전환은 차량 출시 이후에도 새로운 수익 기회를 창출할 수 있는 잠재력을 지니지만 3, 동시에 기존 개발 방식의 한계를 극명하게 드러냈다.

전통적인 차량 개발 방식의 핵심 한계는 다음과 같다:

1. 하드웨어 종속성: 역사적으로 자동차 임베디드 소프트웨어는 특정 프로세서(SoC)와 함께 제공되는 BSP(Board Support Package)의 고유 API에 종속되어 작성되었다.3 이로 인해 차량 모델이나 세대가 변경되어 하드웨어가 바뀌면, 기존 소프트웨어의 이식성(portability)이 보장되지 않았다.3 이는 코드 재사용을 극도로 어렵게 만들고, 모든 신규 플랫폼마다 막대한 소프트웨어 통합 및 검증 비용을 발생시켰다.3

2. ’Shift-Left’의 부재: 전통적인 V-모델 개발 프로세스는 SDV의 요구를 충족하기 어렵다.5 V-모델은 개발 주기의 가장 후반부에 통합 및 테스트가 집중되어, 결함이 뒤늦게 발견되고 이는 막대한 수정 비용을 초래한다.5 반면 SDV는 출시 후에도 OTA(Over-The-Air)를 통해 지속적인 기능 업데이트와 안전성 개선을 요구한다.5

이러한 기술적, 비용적 문제를 해결하기 위해 SOAFEE가 필요하게 되었다. SOAFEE의 탄생은 기술적 이상뿐만 아니라, OEM의 강력하고 실질적인 비즈니스 요구에 의해 주도되었다. Arm에 따르면, OEM들은 SDV로의 전환 과정에서 발생하는 개발 비용과 복잡성이라는 두 가지 핵심 장벽을 낮추기 위해 세 가지 핵심 요구사항을 전달했으며, 이는 SOAFEE의 근간이 되었다 8:

1. 저가형부터 고가형 차량에 이르기까지 다양한 하드웨어 플랫폼에서 동일한 소프트웨어를 이식하고 사용할 수 있어야 한다 (소프트웨어 이식성 및 재사용).

2. 클라우드(개발 환경)와 엣지(차량 환경) 간의 소프트웨어 일관성을 유지해야 한다 (환경 동등성).

3. 실제 하드웨어(실리콘)가 가용해지기 전에 소프트웨어를 먼저 개발할 수 있어야 한다 (‘Shift-Left’).

결론적으로, SOAFEE는 SDV가 야기한 폭발적인 소프트웨어 복잡성, 하드웨어 종속성으로 인한 비용 증가, 그리고 느린 개발 속도라는 산업계의 고질적인 문제를 해결하기 위한 표준화된 응답이다. 이는 클라우드 네이티브라는 검증된 패러다임을 도입하여 개발 비용을 절감하고 3, 소프트웨어 재사용성을 극대화하며 8, 시장 출시 시간을 단축하려는 9 자동차 업계의 합의된 전략이다.

2. SOAFEE 기술 아키텍처 심층 분석

2.1 클라우드 네이티브 원칙의 차량용 임베디드 적용

SOAFEE 아키텍처의 핵심은 클라우드 인프라 시장과 CSP(Cloud Service Providers)가 복잡한 대규모 소프트웨어 배포 문제를 해결하기 위해 채택한 “클라우드 네이티브(Cloud-Native)” 모범 사례를 차량용 임베디드 환경에 맞게 적용하는 것이다.3

이는 단순히 특정 기술(예: 컨테이너)을 도입하는 것을 넘어, 개발 워크플로우(DevOps) 3, 설계 패턴(예: 마이크로서비스) 3, 그리고 관련 기술 스택(예: 오케스트레이션)을 총체적으로 이식하는 것을 의미한다.3

SOAFEE의 핵심 원칙은 “클라우드에서 개발하고, 엣지(차량)에 배포”(‘Develop in Cloud, Deploy at the Edge’)하는 것이다.10 이를 실현하기 위해 SOAFEE는 클라우드 기반 가상 환경(시뮬레이션)에서 서비스 개발과 테스트를 선행한 후, 그 결과물을 물리적 하드웨어(차량 ECU)로 원활하게(seamlessly) 배포하는 워크플로우를 지원한다.10

이 원칙이 성공적으로 작동하기 위한 전제 조건은 클라우드 개발 환경과 차량 엣지 배포 환경 간의 “환경 동등성(environmental parity)“을 보장하는 것이다.4 이는 개발자들이 클라우드에서 테스트하고 검증한 소프트웨어가 차량 내부의 이기종 하드웨어에서도 동일하게 작동할 것을 보장해야 함을 의미하며, OEM이 요구한 “클라우드와 엣지 간의 소프트웨어 일관성” 8 요구와 직접적으로 연결된다.

2.2 핵심 소프트웨어 스택: OCI 컨테이너, 마이크로서비스, 쿠버네티스 기반 오케스트레이션

SOAFEE 아키텍처 사양 v1.0 12 및 관련 기술 백서 3는 클라우드 네이티브 원칙을 구현하기 위한 핵심 소프트웨어 스택을 다음과 같이 정의한다.

1. 마이크로서비스 아키텍처 (Microservice Architecture): SOAFEE는 마이크로서비스 설계를 기본 패턴으로 활용한다.3 이는 복잡한 차량 애플리케이션(예: ADAS)을 명확하게 정의된 API 인터페이스를 가진, 느슨하게 결합된(loosely coupled) 협업 서비스의 집합으로 분리하는 방식이다.3 각 서비스는 독립적으로 개발, 테스트, 배포 및 업데이트될 수 있다.

2. 컨테이너 (Containers): 개별 마이크로서비스는 코드와 라이브러리 등 모든 종속성을 포함하는 패키지인 OCI(Open Container Initiative) 호환 컨테이너로 캡슐화된다.3 OCI는 컨테이너 런타임 및 이미지 사양을 정의하는 업계 표준이다.3 OCI 사양을 준수하는 컨테이너는 OCI 호환 런타임이 존재하는 모든 플랫폼에서 수정 없이 작동하는 강력한 이식성(portability)을 보장한다.3

3. 오케스트레이션 (Orchestration): 컨테이너화된 수많은 마이크로서비스의 배포, 구성, 모니터링 및 전반적인 수명 주기는 오케스트레이터(Orchestrator)에 의해 자동화되고 관리된다.3 SOAFEE는 Kubernetes 호환 컨테이너 워크로드 오케스트레이션을 아키텍처의 필수 요소로 명시한다.10 이는 사실상 클라우드 표준인 Kubernetes API를 차량 내부 워크로드 관리의 표준 인터페이스로 채택함을 의미한다.

SOAFEE 아키텍처의 공식 레퍼런스 구현으로는 EWAOL (Embedded Workloads in Arm on Linux)이 있으며 10, 이는 meta-ewaol CI 10를 통해 지속적으로 통합 및 관리된다.

표 1: SOAFEE 아키텍처 핵심 구성요소 및 역할

2.3 하드웨어 추상화 및 이식성 보장 전략 (VirtIO 및 표준 기반 펌웨어)

SOAFEE의 핵심 가치이자 OEM의 최우선 요구사항은 하드웨어와 소프트웨어의 분리 12를 통한 이식성이다.3 이는 소프트웨어(애플리케이션)가 특정 하드웨어(SoC)에 종속되지 않고 다양한 플랫폼에서 재사용될 수 있어야 함을 의미한다.3

이를 위해 SOAFEE는 아키텍처의 기반으로 “표준 기반 펌웨어(Standard Based Firmware)“를 요구하며, 애플리케이션이 이 표준 펌웨어 상에서 수정 없이 실행되는 것을 목표로 한다.10

소프트웨어 이식성을 보장하는 핵심 전략으로 VirtIO 표준의 채택 및 적응이 제시된다.3 VirtIO는 하이퍼바이저 환경에서 게스트 운영체제(Guest OS)가 가상 하드웨어 장치에 접근하기 위해 사용하는 표준화된 인터페이스이다. SOAFEE는 이 VirtIO를 컨테이너 및 오케스트레이션 환경에 적용한다.

VirtIO는 가속기(예: NPU, GPU) 및 고대역폭 I/O 장치에 대한 일관된 가상 인터페이스를 애플리케이션(컨테이너)에 제공한다.3 이를 통해 애플리케이션은 실제 물리적 하드웨어 드라이버가 아닌, 표준화된 VirtIO 인터페이스와 통신한다. 결과적으로, 기반 하드웨어가 변경되더라도 애플리케이션 코드를 해당 하드웨어의 특정 구현에 맞춰 재컴파일할 필요 없이 워크로드 재사용을 극대화할 수 있다.3

SOAFEE는 VirtIO 표준 기구 내에서 업스트림(upstream) 활동을 통해, 기존 IT 환경에는 없었던 CAN 버스나 머신러닝(ML) 가속과 같은 자동차 고유의 인터페이스에 대한 VirtIO 표준 구현을 정의하고, 실시간 제약 조건을 표현하는 작업을 수행하고 있다.3

이 지점에서 SOAFEE의 “하드웨어 비종속성(hardware agnostic)” 1 주장에 대한 정교한 전략이 드러난다. SOAFEE 이니셔티브 자체는 Arm에 의해 강력하게 주도되고 있으며 9, Arm Neoverse 및 Cortex-A 플랫폼(Armv9 아키텍처, Automotive Compute Subsystems)을 기반으로 구축되었다.9 이는 모순처럼 보일 수 있으나, 실제로는 고도로 계산된 전략이다.

SOAFEE가 추구하는 “하드웨어 비종속성“은 소프트웨어 계층의 목표이다. 이 목표는 OCI 컨테이너, K8s API, 그리고 VirtIO와 같은 표준화된 추상화 인터페이스를 통해 달성된다.3 동시에, 이러한 표준(특히 VirtIO-CAN 등 자동차 특화 인터페이스)의 실질적인 구현은 Arm과 그 생태계(ADLINK 15, Synopsys 7 등)에 의해 주도되고 있다. 결과적으로 Arm은 자사 아키텍처를 SDV를 위한 사실상의 표준(de facto standard) 하드웨어 플랫폼으로 공고히 하는 동시에, OEM에게는 “소프트웨어 이식성“이라는 핵심 가치를 제공하는 윈-윈(win-win) 구조를 구축하고 있다.

2.4 “클라우드 개발, 엣지 배포” DevOps 워크플로우

SOAFEE 아키텍처는 OEM의 세 번째 요구사항이었던 “Shift-Left” 개발 5을 가능하게 하는 핵심 동력이다.

전통적으로 개발자들은 실제 ECU 하드웨어(실리콘)가 생산될 때까지 기다려야만 소프트웨어 통합 및 테스트를 시작할 수 있었다. SOAFEE는 Arm 기반 가상 프로토타이핑(Virtual Prototyping) 9과 클라우드 기술을 결합하여 이 문제를 해결한다.7

개발자는 실리콘이 나오기 전에도 클라우드 환경에서 제공되는 가상 하드웨어 플랫폼을 통해 조기 소프트웨어 프로토타이핑, 개발, 통합 및 테스트를 수행할 수 있다.7 클라우드 기반 가상 테스트는 “거의 무제한적인 용량“을 활용하여 수많은 클라우드 인스턴스에 동시 테스트를 분산시킬 수 있게 한다.7 이는 테스트 커버리지를 비약적으로 확장하고 비용을 낮추며, 개발 사이클 아주 초기에 오류를 감지하게 하여 V-모델의 한계를 극복한다.5 Arm은 이 접근 방식이 개발 시간을 최대 2년까지 단축할 수 있다고 주장한다.9

이러한 클라우드 네이티브 워크플로우는 개발(Dev)과 운영(Ops)이 지속적으로 피드백을 주고받는 진정한 DevOps 프로세스를 차량 개발에 구현한다.3 클라우드에서 개발/테스트된 소프트웨어는 랩 기반 HIL(Hardware-in-the-Loop) 검증을 거쳐 차량에 배포된다. 배포된 컨테이너의 운영 데이터(성능, 오류 등)는 다시 모니터링되어 클라우드의 다음 개발 사이클에 피드백된다. 이 폐쇄 루프(closed-loop)는 지속적인 품질 향상(CI), 지속적인 배포(CD)를 가능하게 하여 시장 출시 시간을 단축하고 전반적인 개발 비용을 절감한다.3

3. 자동차 고유의 난제 해결: 안전성, 실시간성, 보안

3.1 근본적 난제: 클라우드 기술의 차량 적용

SOAFEE의 가장 큰 기술적 도전 과제는, 본질적으로 데이터센터를 위해 설계된 클라우드 네이티브 기술을 자동차라는 특수한 임베디드 환경에 적용하는 것이다.11

클라우드 기술은 차량 내부에서 요구되는 몇 가지 핵심 속성이 결여되어 있다. 여기에는 엄격한 기능 안전 인증(Safety certification) 17, 결정론적 실시간 제약 조건(Real-time constraints & determinism) 11, 제한된 하드웨어 리소스(CPU, 메모리) 16, 그리고 가변적이거나 간헐적인 네트워크 연결성 16 등이 포함된다. SOAFEE 아키텍처는 이러한 격차를 메우기 위한 구체적인 확장 및 적응 전략을 포함한다.

3.2 혼합 중요도(Mixed-Criticality) 워크로드의 분리 및 관리

SDV 아키텍처의 핵심 난제는 단일 고성능 칩(SoC)에서 라디오 브라우징(낮은 중요도, Non-Safety)과 전자식 조향 제어(높은 중요도, ASIL-D)와 같이 안전 수준이 완전히 다른 소프트웨어를 동시에 실행(혼합 중요도)하는 것이다.18 한 워크로드의 결함이 다른 안전-필수 워크로드에 영향을 미치는 것을 완벽하게 방지(Freedom from interference)해야 한다.

SOAFEE는 이러한 혼합 중요도 워크로드를 관리하기 위해 기존 클라우드 네이티브 기술을 확장하는 두 가지 핵심 솔루션을 제시한다.3

1. 오케스트레이터 확장: 표준 Kubernetes(K8s) 오케스트레이터는 “ASIL-B“나 “보장된 실행 시간”, “간섭 자유“와 같은 자동차 고유의 요구사항을 이해하지 못한다.3 SOAFEE 워킹 그룹은 이러한 안전 및 실시간 요구사항을 기술(describe)할 수 있는 **정규화된 언어(common language)**를 정의하고, 오케스트레이터가 이를 인지하도록 확장하는 작업을 진행 중이다. 이 확장을 통해 오케스트레이터는 “조향 제어” 컨테이너(Pod)는 특정 안전-격리 코어에 배포하고, “라디오” 컨테이너는 일반 코어에 배포하는 등, 워크로드의 요구사항에 맞춰 지능적인 배포 결정을 내릴 수 있게 된다.3

2. 런타임 가상화 (가상화된 컨테이너 런타임): 안전성 확보를 위해 컨테이너 런타임 자체를 향상시키는 방안으로, runx와 같은 가상화된 컨테이너 런타임을 VMM(Virtual Machine Monitor, 하이퍼바이저)과 함께 사용하는 방안이 제안된다.3 이 구조에서 VMM은 하드웨어 접근 등 권한 있는 시스템 리소스 제어를 담당하고, 컨테이너 런타임 자체는 낮은 권한의 실행 환경에서 작동한다. 이 명확한 권한 분리 및 격리(isolation)는 한 컨테이너가 시스템의 다른 안전-필수 부분에 영향을 미치는 것을 원천적으로 차단하여 안전성을 확보한다.3

3.3 기능 안전(FuSa) 및 실시간성(Real-Time) 확보

대부분의 클라우드 네이티브 기술 스택은 ISO 26262와 같은 기능 안전 인증을 받지 않았다.17 SOAFEE는 아키텍처 자체가 모든 안전성을 제공하는 것이 아니라, 안전한 워크로드가 실행될 수 있는 프레임워크를 제공하고, 필요한 기술은 생태계 파트너들이 제공하도록 유도한다.

SOAFEE 아키텍처는 실시간(Real-Time) 요구사항을 워크로드 분석 단계에서부터 소프트웨어 스택 설계, 하드웨어 상호작용에 이르는 전 과정에서 고려해야 함을 명시한다.11

이를 위해 기능 안전 전문 기업들이 SOAFEE 생태계에 적극적으로 참여하고 있다. 예를 들어, Apex.AI는 ROS 2(Robot Operating System)의 기능 안전 인증 버전 개발 경험을 SOAFEE에 기여하고 있다.18 또한, DENSO와 같은 주요 Tier 1 공급업체는 SOAFEE 프레임워크 내에서 작동하는 SDV용 **결정론적 미들웨어(deterministic middleware)**를 개발하여 실시간성을 보장하는 솔루션을 제공한다.19

3.4 임베디드 환경 제약 극복 (경량 컨테이너 및 리소스 최적화)

전통적인 클라우드용 컨테이너 플랫폼은 데이터센터의 풍부한 리소스를 가정하므로, 차량 내부의 제한된 하드웨어 리소스(메모리, CPU) 환경에는 적합하지 않다.16

SOAFEE 생태계는 이 문제를 해결하기 위한 특화된 솔루션을 제공한다. AosEdge와 같은 플랫폼은 “임베디드 시스템에 최적화된 목적 기반의 경량 컨테이너(purpose-built lightweight containers)“를 제공한다.16 이러한 경량 컨테이너는 OCI 호환성을 유지하면서도, 최소한의 리소스 사용으로 세분화된 업데이트(granular updates)를 가능하게 하여 16 임베디드 환경의 제약을 극복한다.

3.5 엔드-투-엔드(End-to-End) 보안 프레임워크 및 OTA 업데이트 전략

SOAFEE 아키텍처는 SDV의 복잡한 소프트웨어 스택을 보호하기 위해 강력한 엔드-투-엔드 보안 원칙을 아키텍처 가이드라인에 포함한다.11

• 최소 권한의 원칙 (Principle of least privilege): 인프라(컨테이너 런타임, 오케스트레이터)와 애플리케이션 모두에 적용된다.

• 표준 기반 보안 서비스: 암호화(cryptography), 증명(attestation) 등 공통 보안 서비스를 지원하며, SOAFEE가 자체 API를 정의하는 대신 W3C API 16와 같은 **사용 가능한 표준(available standards)**에 기반한 강력한 보안 API 사용을 의무화한다.11

• 애플리케이션 인증: 배포된 컨테이너가 신뢰할 수 있는 출처에서 왔는지, 그리고 저장소에서 수정되지 않았는지 확인하는 절차를 포함한다.

• 안전한 코딩 및 검증: CERT 코딩 가이드라인 준수 및 정적 분석 수행을 제안한다.11

이러한 보안 프레임워크는 SOAFEE가 지향하는 클라우드 네이티브 DevOps 워크플로우와 결합하여 안전하고 효율적인 OTA(Over-The-Air) 업데이트를 가능하게 한다.5 AosEdge와 같은 생태계 솔루션은 보안이 강화된 OS 커널과 격리된 도메인을 제공하며, 차량의 네트워크 연결이 간헐적으로 끊어지는 실제 주행 상황에서도 원활한 배포 및 수명 주기 관리를 지원한다.16

이 모든 난제 해결 전략에서 SOAFEE의 가장 정교한 지점은, 자동차 산업의 고유한 요구사항(안전, 실시간)을 해결하기 위해 새로운 고립된 표준을 만드는 대신, 기존 클라우드 표준(OCI, K8s, VirtIO)을 “확장“하고 그 결과를 다시 “업스트림(upstream)” 3하는 전략을 채택했다는 것이다.

예를 들어, K8s에 실시간 속성을 기술하는 언어를 추가하거나 3, VirtIO 표준에 CAN 버스를 추가하는 3 작업을 수행하고, 이를 다시 OCI나 VirtIO 표준 위원회에 업스트림으로 제안한다. 이 전략이 성공하면, 자동차 산업은 안전과 실시간이라는 특수성을 만족시키면서도, 거대한 글로벌 클라우드 개발자 생태계 2의 이점을 동시에 누릴 수 있게 된다. 이는 SOAFEE가 고립된 자동차 표준이 아닌, 클라우드 네이티브라는 거대한 기술 흐름에 합류하려는 고도의 전략이다.

4. SOAFEE 생태계와 거버넌스

4.1 SIG(Special Interest Group) 운영 체계

SOAFEE는 Arm을 비롯한 창립 멤버들이 설립한 SIG(Special Interest Group)에 의해 운영된다.4 이 개방형 거버넌스 4는 아키텍처의 협력적 진화와 생태계의 성공적인 확장을 보장한다.

SIG 조직은 3개의 핵심 위원회로 구성된다 4:

1. 거버닝 보드 (Governing Body): 창립 멤버들로 구성되며, SOAFEE의 전략적 비전을 설정한다.

2. 기술 운영 위원회 (TSC, Technical Steering Committee): SOAFEE의 기술적 비전, 아키텍처, 그리고 실행을 주도한다. TSC는 특정 주제를 심층적으로 다루는 워킹 그룹(WG)을 생성하고 조정한다.4

3. 마케팅 운영 위원회 (MSC, Marketing Steering Committee): 백서, 웹사이트, 소셜 미디어 등 마케팅 자료를 개발하고, 생태계 확장을 위한 GTM(Go-To-Market) 전략을 수립한다.4

SOAFEE 멤버십은 가입비가 없으며(free), 조직이나 개인이 기여하고자 하는 의사와 전문성(expertise and technology know-how)을 기반으로 한다.1 파트너십 수준은 SOAFEE 커뮤니티에 제공하는 리소스에 의해 결정된다.1

4.2 주요 회원사 현황 및 산업 내 영향력

SOAFEE의 진정한 경쟁력은 아키텍처 사양 자체보다, 이를 지지하고 참여하는 방대하고 빠르게 성장하는 생태계에 있다.

SOAFEE는 2021년 9월 8개의 창립 멤버로 시작하여 21, 1년 만인 2022년 10월까지 50개 이상의 회원사로 4배 성장했다.22 3주년(2024년경)에는 120개 이상 8, 그리고 2025년 10월 기준 150개 이상의 회원사를 확보하며 14 폭발적인 성장세를 기록했다.

이 생태계는 자동차 공급망 전체를 아우른다는 점에서 강력한 영향력을 발휘한다. 회원사들은 OEM, Tier 1, 반도체 및 IP 공급업체, 시스템 통합자(SI), OS 및 독립 소프트웨어 벤더(ISV), 그리고 클라우드 서비스 제공자(CSP)를 모두 포함한다.22

주요 회원사 현황은 다음과 같다:

• OEM: General Motors (GM), Geely, Tata Motors 8, Nissan 23, Volkswagen 그룹의 소프트웨어 자회사인 CARIAD.6

• Tier 1 공급업체: Panasonic Automotive Systems (거버닝 보드 멤버) 1, DENSO 19, LG Electronics.25

• 반도체 및 IP: Arm (이니셔티브 주도) 9, Synopsys.7

• 소프트웨어 및 클라우드: Red Hat 1, Apex.AI (기능 안전 전문) 18, STRADVISION (ADAS 및 딥러닝 인식 기술 전문) 14, Ferrous Systems (Rust 언어 안전성) 23, Skygrid (차량 기반 AI 인프라).23

이러한 생태계의 폭발적인 성장은, 특히 GM, 닛산, 폭스바겐 등 글로벌 핵심 OEM들이 SOAFEE에 참여하고 있다는 사실에서 기인한다. 이는 이들 OEM이 SOAFEE를 SDV 시대를 위한 사실상의(de facto) 표준 아키텍처로 간주하고 있음을 강력하게 시사한다.

OEM이 SOAFEE 표준을 채택함에 따라, 강력한 네트워크 효과(network effect)가 발생한다. Tier 1(파나소닉, 덴소) 19과 소프트웨어 벤더(Apex.AI, STRADVISION) 14는 이들 OEM에 부품과 소프트웨어를 공급하기 위해 생존 전략으로서 SOAFEE 호환 제품을 개발해야만 한다. 이 선순환 구조는 SOAFEE 생태계를 더욱 공고히 하여, 후발 주자나 경쟁 표준이 진입하기 어려운 강력한 “경제적 해자(economic moat)“를 구축한다.

4.3 레퍼런스 구현 (EWAOL) 및 활용 사례 (블루프린트)

SOAFEE는 추상적인 아키텍처 사양에 그치지 않고, 이를 실제로 구현하고 검증하는 구체적인 실행 전략을 보유하고 있다.

• 레퍼런스 구현 (EWAOL): SOAFEE는 GitLab을 통해 EWAOL (Embedded Workloads in Arm on Linux)이라는 공식 오픈 소스 레퍼런스 구현을 제공한다.10 EWAOL은 SOAFEE 아키텍처 사양(예: v1.0 12)을 실제로 구현한 코드 베이스이며, 사양 문서의 릴리스 번호를 따른다.10

• 블루프린트 (Blueprints): 블루프린트는 SOAFEE의 핵심 실행 전략이자 가장 실질적인 결과물이다.26 블루프린트는 “특정 자동차 유스케이스(use-cases)에 의해 주도되는 예시적인 레퍼런스 애플리케이션 소프트웨어 솔루션“으로 정의된다.11

• 블루프린트의 목적: 블루프린트의 목적은 SOAFEE 아키텍처 개념(예: ‘클라우드 개발, 엣지 배포’)을 실제 유스케이스를 통해 검증(validate)하고, 회원사들이 자사 제품의 프로토타이핑 및 개발을 가속화할 수 있도록 참조점을 제공하는 것이다.11

주요 블루프린트 및 SOAFEE 적용 사례는 다음과 같다:

• LG 전자 “PICCOLO”: LG전자가 SDV 혁신을 위해 SOAFEE와 협력하여 개발한 기술.25

• VicOne “Edge AI Threat Detection”: SOAFEE 아키텍처를 기반으로 차량 엣지에서 실행되는 적응형 AI 위협 탐지 솔루션.27

• Open AD Kit / Autoware: ADAS 및 자율주행 개발을 위한 Open AD Kit 블루프린트가 런칭되었으며 21, ADLINK의 SOAFEE 개발 플랫폼은 Open Robotics ROS 2와 Autoware.Auto를 레퍼런스 애플리케이션으로 사용한다.15

이러한 블루프린트 개발 및 검증은 SOAFEE Integration Lab을 통해 이루어진다.12 통합 랩은 회원사들이 SOAFEE 환경에서 자사의 기술과 전문성을 테스트하고, 표준화된 인터페이스를 통해 상호 운용성을 검증할 수 있는 협업 공간을 제공한다.26

5. 산업 표준 포지셔닝 및 상호 운용성

5.1 SOAFEE 대(對) AUTOSAR (Classic/Adaptive) 비교 분석

SOAFEE를 이해하기 위해서는 기존 자동차 산업의 지배적 표준인 AUTOSAR(AUTomotive Open System ARchitecture)와의 관계를 명확히 정립하는 것이 필수적이다. AUTOSAR는 Classic Platform (CP)과 Adaptive Platform (AP)으로 나뉘며, SOAFEE와는 목적과 역할이 근본적으로 다르다.

1. Classic AUTOSAR (CP): 28

• 목표: 깊이 임베디드된(deeply embedded) ECU의 제어. 파워트레인, 섀시, 바디 제어 등.

• 실시간성: Hard Real-time (마이크로초 단위의 엄격한 시간 보장).

• 안전성: 최고 등급인 ASIL-D 지원 가능.

• 아키텍처: 정적(Static) 구성. C 언어 사용. Signal 기반 통신 (CAN, LIN).

• 업데이트: 런타임 업데이트 불가. 업데이트 시 전체 ECU 코드(펌웨어)를 교체해야 함.

2. Adaptive AUTOSAR (AP): 28

• 목표: 고성능 컴퓨팅(HPC). ADAS 도메인 컨트롤러, IVI, 게이트웨이 등.

• 실시간성: Soft Real-time (밀리초 단위).

• 안전성: ASIL-B 수준 지원.

• 아키텍처: 동적(Dynamic) 구성. C++ 언어 사용. POSIX 호환 OS 기반. 서비스 지향 아키텍처(SOA) 및 Service-Oriented 통신 (Ethernet, SOME/IP).

• 업데이트: 런타임 중 동적 배포 및 OTA(Over-The-Air) 업데이트 지원.

3. SOAFEE: 3

• 목표: 클라우드 네이티브 개발 패러다임 도입. 소프트웨어의 배포 및 수명 주기 관리.

• 실시간성: 클라우드 기술 기반이므로 본질적으로 실시간이 아니나, 아키텍처 확장을 통해 혼합 중요도 및 실시간 워크로드의 관리를 목표함.

• 아키텍처: 컨테이너(OCI), 마이크로서비스, K8s 호환 오케스트레이션.

• 업데이트: 클라우드 네이티브 CI/CD 및 OTA 업데이트에 최적화된 워크플로우 제공.

이 세 가지 표준은 경쟁 관계가 아니라, 차량 내에서 서로 다른 계층(Layer)과 목적을 갖는 보완적 관계이다.

표 2: SOAFEE와 AUTOSAR 플랫폼 비교 (역할, 아키텍처, 실시간성)

5.2 SOAFEE와 AUTOSAR의 보완적 관계

SOAFEE는 AUTOSAR를 대체하지 않는다.4 SOAFEE는 AUTOSAR를 *보완(complement)*한다.34

이에 대한 가장 강력한 증거는, SOAFEE가 실제 차량 배포에 어떻게 사용될 수 있는지 보여주기 위해 AUTOSAR Adaptive 플랫폼과 Classic 플랫폼을 사용하는 예제 블루프린트를 계획하고 있다는 사실이다.33

이 둘의 관계는 “관리자(SOAFEE)와 전문가(AUTOSAR)“로 비유할 수 있다.

Adaptive AUTOSAR는 C++ 기반의 고성능 서비스를 실행하기 위한 애플리케이션 런타임(runtime) 환경을 제공한다.28 반면 SOAFEE는 OCI 컨테이너를 *배포하고 관리(orchestrate)*하는 프레임워크를 제공한다.3

따라서 가장 논리적이고 효율적인 아키텍처는, Adaptive AUTOSAR 표준에 따라 개발된 애플리케이션(서비스)을 OCI 컨테이너로 패키징하고, SOAFEE의 Kubernetes 기반 오케스트레이터가 이 컨테이너의 배포, OTA 업데이트, 모니터링, 리소스 할당 등 전반적인 수명 주기를 관리하는 것이다.

즉, AUTOSAR는 “무엇을(What)” 실행할지(애플리케이션 로직)를 정의하고, SOAFEE는 “어떻게(How)” 그것을 배포하고 관리할지(라이프사이클)를 정의한다. SOAFEE는 AUTOSAR 워크로드를 포함한 차량 내 모든 소프트웨어 워크로드를 담는 표준화된 그릇이자 관리 시스템의 역할을 수행한다.

5.3 SDV 얼라이언스: AUTOSAR, COVESA, Eclipse SDV와의 표준화 협력

SDV 시대로 접어들면서, AUTOSAR, COVESA(Connected Vehicle Systems Alliance), Eclipse SDV, 그리고 SOAFEE 등 여러 컨소시엄이 각자의 영역에서 표준을 개발하며 잠재적인 표준 파편화(fragmentation) 및 상호 운용성 문제가 업계의 큰 우려로 대두되었다.35

이 문제를 해결하기 위해 2023년 3월, 이 4개의 주요 컨소시엄은 **“SDV 얼라이언스(SDV Alliance)”**라는 이름의 “협업의 협업(collaboration of collaborations)“을 공식 발표했다.35

SDV 얼라이언스의 목표는 명확하다: SDV 생태계의 노력을 조율(align)하고, SDV에 대한 명확하고 통일된 정의(unified definition)에 합의하며, 각 조직의 기술, 방법론, 표준이 SDV 개발을 위해 “어떻게 함께 작동할 수 있는지“를 구체적으로 보여주는 것이다.35 SDV는 단일 컨소시엄이 처리하기에는 너무 복잡하다는 35 업계의 공감대가 형성된 결과이다.

SDV 얼라이언스는 CES 2024에서 각기 다른 조직의 기술(예: COVESA의 데이터 표준, SOAFEE의 배포)이 함께 작동하는 공동 데모를 시연하며 35 이 협력이 실질적인 성과를 내고 있음을 증명했다.

SDV 얼라이언스의 결성은 SDV 개발의 가장 큰 장애물이 개별 기술의 부족이 아니라 표준의 파편화였음을 업계가 공식적으로 인정한 것이다. 이는 OEM과 Tier 1이 표준화 단체들에게 경쟁이 아닌 협력을 요구한 결과로 해석되며, 이로써 업계는 마침내 SDV를 위한 통합된(unified) 표준 스택의 청사진을 갖게 되었다.

이 통합 스택에서 각 조직의 역할은 다음과 같이 명확해진다:

• AUTOSAR: 기능 안전 및 실시간 애플리케이션 런타임 제공.

• COVESA: VSS(Vehicle Signal Specification) 등 차량 데이터 및 서비스 표준 정의.

• Eclipse SDV: 표준 구현을 위한 오픈 소스 도구 및 프레임워크 제공.

• SOAFEE: 클라우드 네이티브 배포 및 소프트웨어 수명 주기 관리 아키텍처 제공.

이 협력을 통해, SOAFEE는 더 이상 SDV를 위한 여러 아키텍처 옵션 중 하나가 아니라, 업계가 공식적으로 합의한 통합 SDV 스택의 “클라우드 네이티브 배포 및 관리 계층“이라는 핵심적인 역할을 확고히 하게 되었다.

6. 결론: SOAFEE 도입의 전략적 함의 및 미래 전망

6.1 자동차 공급망(Supply Chain)에 미치는 영향

SOAFEE는 지난 수십 년간 이어져 온 하드웨어 중심의 자동차 공급망을 근본적으로 변화시킨다.

첫째, 소프트웨어와 하드웨어의 분리 12 및 표준화된 추상화 계층(VirtIO) 3의 도입은 OEM이 특정 반도체(SoC) 공급업체에 대한 기술적 종속성에서 벗어날 수 있게 한다. OEM은 한 번 개발한 소프트웨어 애플리케이션을 다양한 하드웨어 플랫폼, 그리고 여러 차량 모델과 세대에 걸쳐 재사용(code re-use)할 수 있게 되어 3 막대한 개발 및 통합 비용을 절감할 수 있다.3

둘째, OEM은 “차별화되지 않는 미들웨어(non-differentiating middleware)” 개발에 대한 투자를 최소화할 수 있다.7 대신, SOAFEE라는 표준화된 기반 위에서 AI 기반 ADAS 기능 1이나 구독형 서비스 같은 12 차량의 가치를 높이는 차별화된 상위 애플리케이션 개발에 자원을 집중할 수 있다.

셋째, 이는 OEM과 Tier 1 모두에게 “소프트웨어 개념과 기술을 마스터“해야 하는 거대한 도전을 제시한다.6 SOAFEE는 이러한 전사적인 기술 전환(transformation)을 위한 표준화된 프레임워크와 청사진을 제공한다.

6.2 SOAFEE.next 및 AI 기반 차량으로의 확장성

SOAFEE의 궁극적인 목표는 AI 기반의 SDV를 현실화하는 것이다.1 STRADVISION(ADAS 딥러닝) 14, Skygrid(차량 기반 분산 AI 인프라) 23 등 AI 전문 기업들의 생태계 합류는 SOAFEE가 AI 워크로드 처리를 핵심 아키텍처 요구사항으로 고려하고 있음을 보여준다.

SOAFEE는 3주년을 맞아 8 “SOAFEE.next“라는 이름의 향후 기술 개발 계획을 발표했다. 이는 최신 Armv9 자동차 기술(CSS)에 기반한 새로운 AI 지원 레퍼런스 디자인을 포함하며, 가상 플랫폼과의 통합을 더욱 강화하여 ‘Shift-Left’ 개발을 가속화할 것임을 시사한다.8

6.3 SOAFEE 도입을 위한 전략적 제언

본 보고서의 분석에 따르면, SOAFEE는 단순한 기술 스택의 도입이 아니다. 이는 개발 문화(DevOps), 조직 구조, 그리고 비즈니스 모델(서비스 기반 수익) 12의 변화를 포괄하는 근본적인 패러다임 전환이다.

따라서 SOAFEE 도입을 고려하는 자동차 관련 기업은 다음의 전략적 제언을 고려해야 한다.

1. 전사적 프로세스 혁신: SOAFEE를 단순한 “기술 스택“으로 접근하는 것이 아니라, “Shift-Left” 개발 5, 클라우드 기반 가상 프로토타이핑 7, 그리고 지속적 통합/지속적 배포(CI/CD) 파이프라인 3을 포함하는 전사적인 개발 프로세스 및 조직 문화 혁신의 기회로 삼아야 한다.

2. 통합 스택 관점의 접근: SOAFEE의 진정한 가치는 AUTOSAR, COVESA, Eclipse SDV와의 상호 운용성 35을 통해 SDV를 위한 통합 스택을 제공하는 데 있다. 개별 기술이 아닌, SDV 얼라이언스 36가 제시하는 통합된(unified) 아키텍처 관점에서 자사의 기술 로드맵을 수립해야 한다.

3. 생태계 활용 극대화: SOAFEE의 핵심 경쟁력은 생태계이다.22 블루프린트 11와 통합 랩 12에 적극적으로 참여하여 파트너 기술(예: 안전 OS, 결정론적 미들웨어 19, AI 솔루션 27)을 검증하고 활용하여, 자사의 개발 속도를 높이고 차별화된 가치에 집중해야 한다.

SOAFEE는 SDV 시대로의 전환에 따른 피할 수 없는 복잡성과 비용 문제를 해결하기 위해 업계가 스스로 만들어낸 표준화된 해답이다. 이 프레임워크를 성공적으로 내재화하는 기업이 차세대 모빌리티 시장의 주도권을 확보하게 될 것이다.

7. Works cited

1. SOAFEE Homepage | Soafee.io, accessed November 4, 2025, https://www.soafee.io/
2. About SOAFEE | Soafee.io, accessed November 4, 2025, https://www.soafee.io/about-soafee/
3. How the SOAFEE Architecture Brings A Cloud-Native … - NET, accessed November 4, 2025, https://armkeil.blob.core.windows.net/developer/Files/pdf/white-paper/arm-scalable-open-architecture-for-embedded-edge-soafee.pdf
4. SOAFEE Charter and Vision, accessed November 4, 2025, https://www.soafee.io/charter/
5. About Software-Defined Vehicles and SOAFEE | Arm Learning Paths, accessed November 4, 2025, https://learn.arm.com/learning-paths/automotive/openadkit1_container/1_sdv_soafee/
6. For SDVs, Software Is The Biggest Challenge - Semiconductor Engineering, accessed November 4, 2025, https://semiengineering.com/for-sdvs-software-is-the-biggest-challenge/
7. How SOAFEE Enables Next-Generation Connected Vehicles | Synopsys Blog, accessed November 4, 2025, https://www.synopsys.com/blogs/chip-design/soafee-enables-next-gen-connected-vehicles.html
8. SOAFEE Hits Three-year Milestone with No Signs of Slowing Down - Arm Newsroom, accessed November 4, 2025, https://newsroom.arm.com/news/soafee-three-year-milestone
9. SOAFEE: Cloud-Native Architecture for Software-Defined Vehicles – Arm®, accessed November 4, 2025, https://www.arm.com/company/success-library/made-possible/soafee
10. 5. Architecture — SOAFEE Architecture documentation, accessed November 4, 2025, https://architecture.docs.soafee.io/en/latest/contents/architecture.html
11. SOAFEE Architecture, accessed November 4, 2025, https://architecture.docs.soafee.io/_/downloads/en/latest/pdf/
12. Architecture Specification v1.0 Scalable Open Architecture for Embedded Edge (SOAFEE) — SOAFEE Architecture documentation, accessed November 4, 2025, https://architecture.docs.soafee.io/en/latest/index.html
13. SOAFEE - GitLab, accessed November 4, 2025, https://gitlab.com/soafee
14. STRADVISION Joins SOAFEE Special Interest Group to Drive Software-Defined Vehicle Innovation - PR Newswire, accessed November 4, 2025, https://www.prnewswire.com/news-releases/stradvision-joins-soafee-special-interest-group-to-drive-software-defined-vehicle-innovation-302597611.html
15. SOAFEE for Software Defined Vehicles - ADLINK Technology, accessed November 4, 2025, https://www.adlinktech.com/en/soafee
16. SOAFEE Blueprint: AosEdge - Scalable Deployment and Orchestration Platform for Automotive, accessed November 4, 2025, https://www.soafee.io/blog/2025/aosedge-scalable-deployment-and-orchestration-platform-for-automotive/
17. 3. Challenges Ahead — SOAFEE Architecture documentation, accessed November 4, 2025, https://architecture.docs.soafee.io/en/latest/contents/challenges.html
18. Apex.AI joins SOAFEE, accessed November 4, 2025, https://www.apex.ai/soafee
19. DENSO’s Software-defined Vehicle Vision: Why SOAFEE Matters - YouTube, accessed November 4, 2025, https://www.youtube.com/watch?v=lx49QuYxWpk
20. Members | Soafee.io, accessed November 4, 2025, https://www.soafee.io/members/
21. SOAFEE SIG, One Year Later - NET, accessed November 4, 2025, https://armkeil.blob.core.windows.net/developer/Files/pdf/white-paper/soafee-sig-one-year-later.pdf
22. More than 50 Members Join SOAFEE to Enable the Software-defined Vehicle of the Future, accessed November 4, 2025, https://newsroom.arm.com/news/more-than-50-members-join-soafee
23. Newsroom | Soafee.io, accessed November 4, 2025, https://www.soafee.io/news/
24. SOAFEE architecture for embedded edge enables software defined cars, accessed November 4, 2025, https://www.embedded.com/soafee-architecture-for-embedded-edge-enables-software-defined-cars/
25. SOAFEE in Action, accessed November 4, 2025, https://www.soafee.io/soafee-in-action/
26. SOAFEE and Embedded Computing Design collaborate on campaign to highlight SOAFEE Blueprints, accessed November 4, 2025, https://www.soafee.io/news/2025/soafee-ecd-announcement/
27. SOAFEE Blueprint: Boosting Efficiency and Reducing Cloud Costs Through Adaptive Edge AI Threat Detection - VicOne, accessed November 4, 2025, https://vicone.com/blog/soafee-blueprint-boosting-efficiency-and-reducing-cloud-costs-through-adaptive-edge-ai-threat-detection
28. Comparison of AUTOSAR Classic and Adaptive Platforms - MATLAB & Simulink, accessed November 4, 2025, https://www.mathworks.com/help/autosar/ug/autosar-platform-comparison.html
29. Adaptive AUTOSAR vs Classic AUTOSAR - Embitel, accessed November 4, 2025, https://www.embitel.com/blog/embedded-blog/adaptive-autosar-vs-classic-autosar
30. Differences and Benefits of Classic AutoSAR and Adaptive AutoSAR - Ecotron, accessed November 4, 2025, https://ecotron.ai/blog/differences-and-benefits-of-classic-autosar-and-adaptive-autosar/
31. #ETAStechinsights | Classic vs Adaptive AUTOSAR: Key Differences, Use Cases & How They Work Together - YouTube, accessed November 4, 2025, https://www.youtube.com/watch?v=7S_CfRzYCQA
32. SOAFEE | Embedia - Software Defined Systems, accessed November 4, 2025, https://www.embedia.io/blog/soafee
33. ENABLING CONTINUOUS INNOVATIONS - Autosar, accessed November 4, 2025, https://www.autosar.org/fileadmin/user_upload/AUTOSAR_20th-Book_FINAL_WEB_19-OCT-2023.pdf
34. Standards for Software-Defined Vehicles and E/E Architectures - SDV Guide, accessed November 4, 2025, https://www.sdv.guide/sdv101/part-c-building-blocks/standards-for-software-defined-vehicles-and-e-e-architectures
35. News & Events - Collaboration, The Key to Making the Software Defined Vehicle a Reality, accessed November 4, 2025, https://www.autosar.org/news-events/detail/collaboration-the-key-to-making-the-software-defined-vehicle-a-reality
36. Deterministic and Reliable Software-Defined Vehicles: key building blocks, challenges, and vision - arXiv, accessed November 4, 2025, https://arxiv.org/html/2407.17287v2